単一責任の原則(変更する理由はたった1つ原則) (SRP)
Single Responsibility Principle, SRP
「単一責任の原則」と呼ぶと誤解を招くので、「変更する理由はたった1つ原則」などと呼んだほうがいいと思うmrsekut.icon
参考
あまり読む意味ない
この原則も、字義のままに「単一責任」であるとはならないだろうmrsekut.icon
当然の前提として、「目的に沿ったある側面で単一責任」と判断する
故に人にって単一かどうかが異なるのは当然に起こる
ほんとうの意味で単一にするなら、1ファイルにつき1変数みたいになりそう
良い
そのmoduleやclassに対するアクターを単一にすべき こう考えることで
「moduleの単一責任ってなんやねん」という疑問から
「アクターの分類ってどうやるねん」に変わる
主張
個々のモジュールを変更する理由はたった1つにするのが良い
「そのモジュールの責任(役割)」を「変更(修正)理由」と定義している
ここでのモジュールは恐らく「class」を主眼としている
軽い感想
「数学的、論理的に正しい」と思われるモジュールの分離はここではさほど価値がない
故に、ビジネスの種類(あるいはステークホルダー)が異なれば、同じドメインを扱っていてたとしても、同じclassに入れるべきものは異なる
『Clean Architecture』.iconのp.81で「この法則が誤解される原因は名前があまり良くなかったことだ」と言っている
良くなさすぎるmrsekut.icon
この原則の主張の定義上、間違ってはないと思うけど
誤解しか生まないやろmrsekut.icon
「単一責任を推す原則」として捉えて解説をしてる記事も、アンチ意見も観測した
実際、mrsekut.iconも誤解していた
ということらしいので、「単一責任の原則」は、「単一責任を推す原則」ではない
逆に、修正される理由が同じであれば、(直感的に)別々に思えるものも同一モジュールにすべきなのか？
これを正として、極論を言えば、レイヤードアーキテクチャはあまり筋がよくなくなるとも思う
変更する理由が2つあるということは、機能変更のためにあるクラスを変更すると別の機能が壊れる可能性がある
「これは常にコンテキストによって決まる」
途中までしか読んでないが良さみを感じた